📲 You can test the changes from this Pull Request in WooCommerce iOS by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS
	Build Number	pr11683-e1c1d81
	Version	16.8
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	e1c1d81
	App Center Build	WooCommerce - Prototype Builds #7637

Thanks for taking care of this!

I have two questions/notes:

• I believe we're aiming to disallow referencing dependencies by commit, and that CI checks will start to fail if we do so (at least for pods, I'm not sure if SPM is also included in this, but might be something to check with infra before moving forward, here's the context: p1704255760658109-slack-CC7L49W13
• Is there any concern regarding referencing a un-merged PR from their library?

• I believe we're aiming to disallow referencing dependencies by commit, and that CI checks will start to fail if we do so (at least for pods, I'm not sure if SPM is also included in this, but might be something to check with infra before moving forward, here's the context: p1704255760658109-slack-CC7L49W13

If I understand the expected behavior that will be enforced in the future correctly p1704280854743209/1704255760.658109-slack-CC7L49W13, we only want to point libraries to a commit and non-commit references won't be allowed after Gio's PR Automattic/dangermattic#30 🤔 I'd think the same principle applies to SPM, but it might be worth double-checking with apps-infra.

• Is there any concern regarding referencing a un-merged PR from their library?

Good question, referencing a commit in an un-merged PR might be problematic if they do squash merge or if the author does a force push. It's tricky that we can't use the main branch because of the outstanding issue, maybe we can fork the library (we probably want to check with apps-infra about how to do this so that the forked repo is an A8C repo) and also ping the PR author / library owner about merging this fix and tagging for release.

Authors PR that is merged is not fully fixing the issue and it looks like the author is not really checking other PRs and issues :/ And he did not even tag that fix with a new version number.

Maybe a fork would be the best way of making sure simple packages like this work properly for us.

What would be the best solution for us?

Maybe we can even write our own shimmer version?

Thanks for the clarifications @jaclync !

What would be the best solution for us?
Maybe we can even write our own shimmer version?

Good question, I don't really have an answer 😅 Since the shimmer is used across multiple views/features let's move the discussion to P2 for a decision. Right now only seems to affect this view, but if the library is sort of abandoned then is certain we'll keep encountering issues as we add more instances of it in the future.

For the specific animation oddness that we were trying to fix initially, I'd say that for the time being we can just remove the .shimmering modifier from OwnerUpgradesView, which seems to fix the issue from a quick testing.

+1 to Gabriel's comment above to p2 the plan to fork the repo / write our own version, and then remove the shimmering modifier for this particular view to fix the issue for now. When we create an issue for the shimmering library change after the plan is finalized, we can add a note about adding the shimmering effect back to this view.

Tnx @iamgabrielma @jaclync for feedback! I will update this PR according to our comments and write a P2 for continuing the discussion 👍

Updated the code and wrote the P2 -> pfoUAQ-7T-p2